In current 3GPP technology (as defined in 3GPP TS 23.402, “Architecture enhancements for non-3GPP accesses”) ANDSF (Access Network Discovery and Selection Function) can provide policies to a mobile terminal (UE) in push or pull mode, as illustrated in FIG. 1 for the general roaming case. These policies control, among others, the offload from the 3GPP access(es) towards non-3GPP access(es)—mostly WLAN—in two variants: (a) seamless and (b) non-seamless offload; this relies on appropriate agreements between the 3GPP operator and non-3GPP operators. The provisioning of offload policies happens via a protocol based on OMA DM (as described in 3GPP TS 24.312, “Access Network Discovery and Selection Function (ANDSF) Management Object (MO)”) and is assumed not to be a real-time process. However, there are several use cases which have been identified by the inventor where the usage of such policies should be controlled in (nearly) real-time:                1. Offload dependent on charging cycle: in some tariffs, after a certain volume threshold of volume (the so called 2nd flat rate threshold) has been reached, the offload of traffic should be favored more than with a consumed volume below the threshold. Although the offload probably cannot be strict (coverage of WLAN is not wide and QoS may not suffice for some services) it is preferred to have a guaranteed and strict point in time, well synchronized with the charging system, so that users can also understand the tariff and its usage.        2. Overload situation: if the 3GPP access(es) is/are becoming overloaded, it is strongly preferred to apply policies resulting in more effective offload and for more users. This would benefit both users (as they can continue services which they otherwise could not) and the 3GPP operator (as s/he avoids bad image, complaints and churn or users). The special offload policies for overload need to be activated more or less in real time (ideally within a few seconds) for many users.        3. Gradual construction and provision of ANDSF (offload) policies, e.g. detecting patterns over time, location and usage: for practical reasons it could be desired NOT to activate policies immediately in such a process (although they then have already been delivered to the UE). At the same time it may not be possible or preferred to specify a fixed point in time when policies should become active (note that ANDSF policies of course can be specified with concrete time parameters). Rather, the operator may want to use a kind of activation trigger, on demand. It is noted that a delta mode of policy provisioning is possible only from OMA DM version 1.3 onwards (as of today 3GPP builds still on version 1.2).        4. Business needs, like the support for a marketing campaign where offload to non-3GPP access plays a role. This could be a bundling with services in any relationship to the non-3GPP access provider (e.g. a coffee-shop chain could offer local content which is accessible only via the associated local WLAN hot-spots). As this requires quite some flexibility in configuration and control, a real-time activation of offload policies should support this case.        
The problem with current technology is that (nearly) real-time activation of ANDSF policies is not possible and thus the above mentioned use cases cannot be supported.